Buttons that call HTTP
This is the outbound half of the bridge: a button press, a state change, a Crestron Home scene or a schedule reaching anything that speaks HTTP — with no driver written for it.
Where a request fires from
A request can be attached in two places on a control:
- On entering a state — fired whenever the control enters that state, however it got there: a press, a Crestron Home program, or an inbound webhook.
- On every press — fired on any press, before the state changes, even for a status-only control.
Open a control in the setup app, expand a state (or the On every press section), and press Add request.
Building a request
Each request has:
| Field | What it is |
|---|---|
| Method | GET, POST, PUT, PATCH or DELETE. |
| URL | The endpoint to call. May contain placeholders. |
| Body | The request body, for POST/PUT/PATCH. Templated. |
| Content-Type | Defaults to application/json. |
| Headers | Any headers the endpoint needs. Header values are templated. |
| Authentication | None, Basic (user + password), Bearer token, or a header key (e.g. X-API-Key). |
| Timeout | How long to wait, capped at 30 seconds — a tile must not hang on a slow endpoint. |
| Delay before sending | Wait this long before firing. See macros. |
| Ignore TLS certificate errors | For LAN gear with a self-signed certificate. Leave off for anything on the internet. |
Placeholders
Any URL, header value or body can carry placeholders that are filled in when the request fires:
| Placeholder | Value |
|---|---|
{element} / {index} | The control's number. |
{elementName} | The control's name. |
{state} | The state index being entered. |
{stateName} | That state's label. |
{value} | A level (for a toggle-slider), or a value a webhook passed in. |
{timestamp} | The current time, ISO-8601 UTC. |
{var:name} | A named variable — settable by a webhook, so an outside value can flow into a request body. |
An unknown placeholder is left exactly as written rather than blanked, so a typo like {stat} arrives at
the far end and tells you what went wrong — rather than silently sending nothing.
Sequencing a macro
A state or a press can fire a list of requests, in order. Give each a delay and the list becomes a macro:
POST http://gate/unlock— delay 0GET http://light/on— delay 2000
"Unlock the gate, wait two seconds, turn the light on" — without a scripting language for it.
Confirming the result
Optionally, read the response and use it to set the control's state — Read the response to confirm the
state. Pick how to read the reply (a JSON path like result.relay.0.ison, a regex, or the whole body)
and map each extracted value to a state. This turns an optimistic button into an honest one: the control
shows what the device actually reported, not what you hoped the request did.
Send a test request
The single most useful button in the app. Send test request fires the request from the driver (not the browser, so it reaches the LAN and applies the same rules a real press would) and shows exactly what came back — the status code, the time it took, and the response body.
Every misconfigured header, wrong path or unreachable host is caught here in a second, instead of becoming a return visit. Fire the request, read the response, fix it, fire it again.
The activity log
The Activity tab shows the last ~100 calls in and out, newest first — each with its direction, target, status and timing. It is the fastest way to answer "did that actually fire, and what did it say?" without opening a processor console.
The activity log lives in the driver's memory and is cleared on a reboot. It is a commissioning and debugging aid, not a permanent record.